home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 713 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  1.3 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.std.c
  4. Subject: va_list, function calls.
  5. Date: 9 Apr 1996 07:11:43 -0500
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4kdk5v$mn@solutions.solon.com>
  8. Reply-To: seebs@solon.com
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. I am unclear on the language in the standard describing this.
  12.  
  13. Consider:
  14.  
  15.     void foo(int bar, ...) {
  16.         va_list ap;
  17.         int i;
  18.  
  19.         va_start(ap, bar);
  20.         for (i = 0; i < bar; ++i)
  21.             baz(&ap);
  22.         va_end(ap);
  23.     }
  24.  
  25.     void baz(va_list *ap) {
  26.         printf("%d\n", va_arg(*ap));
  27.     }
  28.  
  29. Assuming that foo is called like
  30.     foo(1, 1);
  31.     foo(2, 18, 23);
  32.     ...
  33. is this legal?
  34.  
  35. If not, is there a compelling reason?
  36.  
  37. I have a proposal in the works for printf() enhancements, but the
  38. obvious implementation would basically require that it be possible
  39. for a function with a va_list to safely have a child function access
  40. and modify that va_list.  The standard's wording appears to me to
  41. apply only to passing the list itself, not its address.
  42.  
  43. -s
  44. -- 
  45. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  46. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  47. FUCK the communications decency act.  Goddamned government.  [literally.]
  48. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  49.